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REMARKS 



Claims 1, 3 to 4, 8 to 10, 12, 14, 15, 19 to 21, 23, 25, 
26, 30 to 32, 34, 36, 37, and 41 to 43 were pending in the 
application at the time of examination. Claims 1, 3 to 4, 8 to 
10, 12, 14, 15, 19 to 21, 23, 25, 26, 30 to 32, 34, 36, 37, and 
41 to 43 stand rejected under 35 U.S.C. § 103(a) 

Applicant has amended the specification to update the 
status of U.S. Patent Applications cited therein. 

Claims 8, 19 and 30 are amended to correct a spelling 
error. The spelling error is an informality and so the 
amendments do not affect the patentability of these claims. 

Claims 1, 3 to 4, 8 to 9, 12, 14, 15, 19 to 20, 23, 25, 
26, 30 to 31, 34, 36, 37, and 41 to 42 stand rejected under 35 
U.S.C. § 103(a) as being obvious over U.S. Patent No. 
6,966,002, hereinafter referred to as "Saez, " in view of U.S. 
Patent No. 6,640,279, hereinafter referred to as Levy. 

Applicant respectfully traverses the obviousness rejection 
of each of Claims 1, 12, 23, and 34 in view of the combination 
of references. The rejection stated in part: 
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Saez does not explicitly teach: 

The reception of said one or more obfuscated executable 
application programs occurs after obtaining a secret, 
which occurs in response to an enrollment request. In 
contrast, Saez teaches that the obfuscated executable 
application programs are received after the enrollment 
request is issued but before a secret is obtained. After 
further consideration, examiner determines that it would 
have been obvious, at the time of the invention to one of 
ordinary skill in the art to which the subject matter 
pertains to modify the Saez invention in order to allow 
the system taught by Saez to receive the program after the 
secret is obtained: 

Sending the program after the secret is obtained would 
allow the server to encrypt the program based on the 
requestor's secret. The requestor can then receive the 
encrypted program and decrypt it accordingly using its 
secret. Examiner deems these processes of 
encrypt ion/decrypt ion are well known in the art. 
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This characterization of Saez not only mischaracterizes 
the teachings of Saez, but renders Saez inoperable. 
Specifically, the rejection asserts that Saez is modified to 
receive the program after the secret is received. However, 
Saez taught that the program was used in obtaining what the 
rejection characterizes as the secret. Specifically, Saez 
taught : 



FIGS. 11A through 11C illustrate the structure of a software 
package including multiple program objects. FIG. 11A provides an 
overall view of the software package illustrating the arrangement of 
an executable notifier 1110 at the head of the package, an optional 
signature section 112 0 at the end of the package, with encrypted and 
compressed program objects 1 and 2 and encrypted access control 
information 1130 arranged between the executable notifier 1110 and 
the signature section 1120. 

The executable notifier 1110 is illustrated in greater detail 
in FIG. 11B. As shown therein, the executable notifier 1110 includes 
a header section 113 5 at the beginning of the software package, 
followed in turn by an executable code section 1140 and a data 
section 1145. The data section 1145 is followed sequentially by a 
resource section 1150 and an import table 1155. The resource section 
1150 supplies various resources which may be employed by the 
executable code of section 1140, such as dialog boxes or menus. The 
import table 1155 includes links to various routines supplied by the 
operating system, such as print, copy, readfile, createfile, etc. 

FIG. 11C illustrates the encrypted portions of the software 
package, including the encrypted access control information 1160 and 
the compressed program objects in the form of N blocks 1165 and 
respective assembly information sections 1170 for each program 
object . 

With reference again to FIG. 11B, the executable code section 
1140 of the executable notifier 1110, in general, exercises control 
over access to the program objects 1 and 2 and performs certain 
ancillary functions, as follows: 

(1) When the user's system first loads the software package in 
memory, the executable code section 1140 runs a setup routine 
utilizing displays and dialog boxes supplied from the resource 
section 1150. The setup routine performs normal setup functions, such 
as a display of the relevant user license and securing the user's 
agreement to the license terms. The executable code section 1140 
refers to information in the operating system of the user's computer 
to determine the language (e.g., English, French, German) in which 
the displays and dialog boxes are presented. 

(2) The executable code section 1140 solicits and evaluates the 
user's requests for access to the program objects. This is achieved 
by displaying a dialog box when the software package is accessed by 
the user. The dialog box explains the user's options, such as which 
programs and/or program options are available without charge, which 
are available for a fee and which of the latter have been purchased 
and are still available to be used. To provide such a display, the 
executable code section references both the access control 
information section 1160 (after decrypting section 1160) and a 
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purchase status file which is produced when the user purchases rights 
to use one or more objects. 

(3) Where a requested use is either free, or already purchased, 
if not free, the executable code section 1140 decrypts and 
decompresses the relevant program or data object, and then loads it 
in memory to be run so that the requested use may be carried out. The 
section 114 0 prevents access to unavailable uses by hooking the 
functions referenced in the import table of the running program 
object to control routines in the executable code section 1140, as 
explained below. 

(4) The executable code section 1140 serves to deter dump 
attacks by erasing from memory certain necessary information from the 
program object when it loads the program object in running format in 
memory. Consequently, even if the decrypted and decompressed program 
object is somehow copied from the memory to some storage device, it 
could not be reloaded in running format in memory and, thus, is 
useless after a dump attack. 

It will be understood that the executable code section 1140 
functions as a "wrapper" or access control executable but without 
being susceptible to various types of attacks that prior art 15, 
wrappers have been subject to. 



Saez, Col. 16, line 62 to Col. 17, line 67. 

Thus, Saez teaches in detail that the software package 
includes multiple different elements including an executable 
notifier that in turn includes an executable code section. The 
executable code section in turn includes code that interacts 
with the user. The executable code solicits and evaluates the 
user's requests for access to the program objects. Saez also 
teaches that a single package is sent to the user irrespective 
of the particular type of program objects included. 

The proposed modification of Saez, as quoted above, does 
not send the software package until after the secret is 
obtained by the user. However, Saez teaches that it is the 
software package that determines whether to request what the 
rejection characterizes as the secret. Accordingly, since the 
rejection proposes to withhold the software package, the 
proposed modification renders Saez inoperable, because the 
executable portion of the software package would be unavailable 
to perform the necessary interactions as required by Saez. 

The MPEP is unambiguous: 
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V. THE PROPOSED MODIFICATION CANNOT RENDER THE PRIOR ART 
UNSATISFACTORY FOR ITS INTENDED PURPOSE 

If proposed modification would render the prior art 
invention being modified unsatisfactory for its intended 
purpose, then there is no suggestion or motivation to make 
the proposed modification. 

MPEP § 2143.01 V., 8 th Ed., Rev. 6, pg. 2100-140 (Sept. 2007). 

The reordering of Saez, as stated in the rejection, 
renders Saez unsatisfactory for its intended purpose. As shown 
in Figs. 12 and 13 of Saez, the first operation in both 
processes (operations 1210 and 1220 in Fig. 12 and operation 
1310 in Fig. 13) is that the user receives the software. This 
is necessary for Saez to achieve its intended purpose as quoted 
above. Therefore, the MPEP indicates the rejection is not well 
founded . 

If the rejection purports to break the package into pieces 
for program objects that require purchase, this changes the 
principles of operation of Saez, because Saez taught that the 
same package was used for all types of program objects, i.e., 
both those that were free and those that requires a purchase. 
Again, the MPEP directs: 



If the proposed modification or combination of the 
prior art would change the principle of operation of the 
prior art invention being modified, then the teachings of 
the references are not sufficient to render the claims 
prima facie obvious. 
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MPEP § 2143.01 VI., 8 th Ed., Rev. 6, pg. 2100-141 (Sept. 2007). 

Since the proposed modification would require a change to 
the principle of Saez that a single package structure is used 
for all objects, both free and purchased, the MPEP indicates 
that the reference is not sufficient to render the claims prima 
facie obvious. 

Finally, general knowledge of a smart card and a virtual 
machine on a smart card fails to establish that Saez could be 
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implemented on such a resource-constrained device. The 
rejection has failed to demonstrate that the complex structures 
and methods of Saez, designed to be used with UNIX and Windows 
(See Col. 9, lines 27 to 42.), could be implemented in the 
limited memory available on a smart card. The use of such 
large operating systems teaches away from implementation on a 
smart card. 

Thus, Applicant has demonstrated that the rejection fails 
to comply with multiple requirements of the MPEP and so a prima 
facie obviousness rejection has not been made. Note that only 
one of the showings is needed to overcome the rejection. 
Applicant respectfully requests reconsideration and withdrawal 
of the obviousness rejection of each of Claims 1, 12, 23, and 
34. 

Applicant respectfully traverses the obviousness rejection 
of Claims 3, 14, 25, and 36 in view Saez. To the extent that 
the obviousness rejection of these claims relies upon modifying 
Saez to move the receipt of the software, the comments above 
are applicable and incorporated herein by reference. 

According to these claims, an enrollment request is 
received from a user device for receipt of one or more 
obfuscated applicant programs. The purchase request of Saez is 
not for a request for receipt of the software package of Saez, 
but rather for purchasing the software. The request for the 
software is different from the purchase request, because the 
request for the software is associated with step 1210 of Saez 
and not the purchase request of step 1230. In view of the 
proposed moving of the delivery of the software, step 1230 does 
not function as noted above and so there is no motivation 
according to the MPEP to make such a modification. 

Further, the rejection failed to consider the claims as a 
whole. The claims recite "associating said secret with said 
target ID following said determining and authentication of said 
enrollment request." The rejection simplifies these claims to 
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receiving, determining and transmitting. Thus, the rejection 
failed to consider the claims as a whole. There is no citation 
to any teaching or suggestion of the associating process, as 
recited in these claims, in the rejection. 

Finally, general knowledge of a smart card and a virtual 
machine on a smart card fails to establish that Saez could be 
implemented on such a resource-constrained device. The 
rejection has failed to demonstrate that the complex structures 
and methods of Saez, designed to be used with UNIX and Windows 
(See Col. 9, lines 27 to 42.), could be implemented in the 
limited memory available on a smart card. The use of such 
large operating systems teaches away from implementation on a 
smart card. 

Thus, Applicant has demonstrated that the rejection fails 
to comply with multiple requirements of the MPEP and so a prima 
facie obviousness rejection has not been made. Applicant 
respectfully requests reconsideration and withdrawal of the 
obviousness rejection of each of Claims 3, 14, 25, and 36. 

Claim 4 depends from Claim 3; Claim 15 from Claim 14; 
Claim 26 from Claim 25; and Claim 37 from Claim 36. Therefore, 
each of Claims 4, 15, 26, and 37 distinguishes over the 
combination of references for at least the same reasons as the 
claim from which each depends. Applicant respectfully requests 
reconsideration and withdrawal of the obviousness rejection of 
each of Claims 4, 15, 26, and 37. 

Applicant respectfully traverses the obviousness rejection 
of Claims 8, 19, 30 and 41 in view of Saez. The above comments 
with respect to the proposed modification to Saez are 
incorporated herein by reference. Moving of the software 
delivery renders Saez incapable of issuing the purchase request 
and hence the server incapable of obtaining the system 
information etc. The required modification renders Saez 
unsuitable for its intended purpose and so a prima facie 
obviousness rejection has not been made. Also, the rejection 
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has failed to demonstrate that the original encryption of the 
software package of Saez was based on a target ID. Applicants 
claim language recites a specific sequence of operations. 
Similarly, Saez teaches a specific sequence of operation that 
provides a software package to a user, and only when the user 
wishes to purchase a part of that package takes additional 
actions. The selective extraction and rearrangement of Saez 
completely changes the principles of operation of Saez. 

Further, general knowledge of a smart card and a virtual 
machine on a smart card fails to establish that Saez could be 
implemented on such a resource -constrained device. The 
rejection has failed to demonstrate that the complex structures 
and methods of Saez, designed to be used with UNIX and Windows 
(See Col. 9, lines 27 to 42.), could be implemented in the 
limited memory available on a smart card. The use of such 
large operating systems teaches away from implementation on a 
smart card. 

Applicant respectfully requests reconsideration and 
withdrawal of the obviousness rejection of each of Claims 8, 
19, 30 and 41. 

Claim 9 depends from Claim 8; Claim 20 from Claim 19; 
Claim 31 from Claim 30; and Claim 42 from Claim 41. Therefore, 
each of Claims 9, 20, 31, and 42 distinguishes over Saez for at 
least the same reasons as the claim from which each depends. 
Applicant respectfully requests reconsideration and withdrawal 
of the anticipation rejection of each of Claims 9, 20, 31, and 
42 . 

Claims 10, 21, 32, and 43 stand rejected as under 35 
U.S.C. § 103(a) as being unpatentable over Saez and Levy in 
view of U.S. Patent No. 6,098,056. 

Applicant respectfully notes that, assuming the 
combination of references is correct, the additional 
information relied upon from the secondary reference fails to 
overcome the deficiency of the primary references with respect 
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to the independent claim from which each of these claims 
depends. In addition, as noted above, the double encryption 
with respect to the purchase request fails to teach anything 
concerning how one of skill in the art would split the 
encryption between steps 1210 and 1230. Moreover, it requires 
modifications to the encryption sequences in Saez that have not 
been acknowledged. General knowledge of double encryption 
fails to teach or suggest how to modify the primary reference 
so that it would still work for its intended purpose and how to 
modify Saez to meet the express sequence recited in these 
claims. Applicant respectfully requests reconsideration and 
withdrawal of the obviousness rejection of each of Claims 10, 
21, 32, and 43 . 

Claims 1, 3 to 4, 8 to 10, 12, 14, 15, 19 to 21, 23, 25, 
26, 30 to 32, 34, 36, 37, and 41 to 43 remain in the 
application. Claims 8, 19, and 3 0 are amended. Claims 2, 5 to 
7, 11, 13, 16 to 18, 22, 24, 27 to 29, 33, 35, 38 to 40 and 44 
to 48 have been cancelled. For the foregoing reasons, 
Applicant (s) respectfully request allowance of all pending 
claims. If the Examiner has any questions relating to the 
above, the Examiner is respectfully requested to telephone the 
undersigned Attorney for Applicant (s) . 
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